1. Field of the Invention
This invention relates to virtualized computer environments, and, in particular, to enforcing restrictions related to a virtualized computer environment.
2. Description of the Related Art
The invention may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. For example, the computer readable media may comprise one or more CDs (Compact Discs), one or more DVDs (Digital Versatile Discs), some form of flash memory device, a computer hard disk and/or some form of internal computer memory, to name just a few examples. An embodiment of the invention, in which one or more computer program modules is embodied in one or more computer readable media, may be made by writing the computer program modules to any combination of one or more computer readable media. Such an embodiment of the invention may be sold by enabling a customer to obtain a copy of the computer program modules in one or more computer readable media, regardless of the manner in which the customer obtains the copy of the computer program modules. Thus, for example, a computer program implementing the invention may be purchased electronically over the Internet and downloaded directly from a vendor's web server to the purchaser's computer, without any transference of any computer readable media. In such a case, writing the computer program to a hard disk of the web server to make it available over the Internet may be considered a making of the invention on the part of the vendor, and the purchase and download of the computer program by a customer may be considered a sale of the invention by the vendor, as well as a making of the invention by the customer.
The invention generally relates to enforcing one or more restrictions related to a virtualized computer environment. The virtualized computer environment may be a virtual machine (VM), for example. It can be a fully virtualized computer, which supports an OS designed to run on whichever hardware platform is virtualized, or a so-called paravirtualized computer, where the OS is modified to communicate or interact in some way with the virtualization software. There may be a wide variety of restrictions that may be enforced in a wide variety of different ways. There may be restrictions related to the general use of a VM, such as who may use the VM, when the VM may be used, and on what physical computers the VM may be used. There may be similar restrictions related to a general ability to modify a VM, such as who may modify the VM. There may also be restrictions related to what modifications may be made to a VM, such as whether the VM may be modified to enable access to various devices or other resources, such as a LAN (Local Area Network), the Internet, a CD-ROM (Compact Disc-Read Only Memory) drive, a floppy disc drive, or a USB (Universal Serial Bus) port. There may also be restrictions related to how the VM may be used and what may be done with the VM. For example, use of the VM to access one or more TCP/IP (Transmission Control Protocol/Internet Protocol) networks may be limited by the address for which access is sought, the protocol being used, or the subject matter of data for which access is sought. A wide variety of other restrictions may also be imposed.
A wide variety of advantages may be realized by enforcing one or more such restrictions, depending on various factors, such as which restriction(s) are enforced, how the invention is implemented, and the environment in which the invention is operating. For example, the invention may be implemented in a corporate environment with a variety of restrictions to improve security on a physical computer in which the invention is implemented, and/or to improve the security of one or more networks to which such a computer is connected. Implementing the invention in a corporate environment may also simplify the task of configuring a group of physical computers for use by individual employees. The invention may also be used to restrict access to licensed computer programs or to restrict access to various types of data, such as sensitive or confidential information or digital entertainment content, such as movies, songs or video games.
One embodiment of the invention is implemented in an existing product of the assignee of this patent, VMware, Inc. This product, which is named the ACE virtualization product, is referred to as a “hosted” virtual computer system. The general architecture of a hosted virtual computer system is described below to provide background for the detailed description of the invention. Other embodiments of the invention may be implemented in a wide variety of other virtualized computer environments, though.
Hosted Virtual Computer System
FIG. 1 illustrates the main components of a “hosted” virtual computer system 100 as generally implemented in the ACE virtualization product of VMware, Inc. The virtual computer system 100 supports a VM 300. As is well known in the field of computer science, a VM is a software abstraction or a “virtualization,” often of an actual physical computer system. As in conventional computer systems, both system hardware 102 and system software 150 are included. The system hardware 102 includes one or more processors (CPUs) 104, which may be a single processor, or two or more cooperating processors in a known multiprocessor arrangement. The system hardware also includes system memory 108, one or more disks 110, and some form of memory management unit (MMU) 106. The system memory is typically some form of high-speed RAM (random access memory), whereas the disk is typically a non-volatile, mass storage device. As is well understood in the field of computer engineering, the system hardware also includes, or is connected to, conventional registers, interrupt-handling circuitry, a clock, etc., which, for the sake of simplicity, are not shown in the figure.
The system software 150 typically either is or at least includes an operating system (OS) 152, which has drivers 154 as needed for controlling and communicating with various devices 112, and usually with the disk 110 as well. Conventional applications 160 (APPS), if included, may be installed to run on the hardware 102 via the system software 150 and any drivers needed to enable communication with devices.
The VM 300—also known as a “virtual computer”—is often a software implementation of a complete computer system. In the VM, the physical system components of a “real” computer are emulated in software, that is, they are virtualized. Thus, the VM 300 will typically include virtualized (“guest”) system hardware 302, which in turn includes one or more virtual CPUs 304 (VCPU), virtual system memory 308 (VMEM), one or more virtual disks 310 (VDISK), and one or more virtual devices 312 (VDEVICE), all of which are implemented in software to emulate the corresponding components of an actual computer. The concept, design and operation of virtual machines are well known in the field of computer science.
The VM 300 also has system software 350, which may include a guest OS 352, as well as drivers 354 as needed, for example, to control the virtual device(s) 312. The guest OS 352 may, but need not, simply be a copy of a conventional, commodity OS. Of course, most computers are intended to run various applications, and a VM is usually no exception. Consequently, by way of example, FIG. 1 illustrates one or more applications 360 (APPS) installed to run on the guest OS 352; any number of applications, including none at all, may be loaded for running on the guest OS, limited only by the requirements of the VM. Software running in the VM 300, including the guest OS 352 and the guest applications 360, is generally referred to as “guest software.”
Note that although the virtual hardware “layer” 302 is a software abstraction of physical components, the VM's system software 350 may be the same as would be loaded into a hardware computer. The modifier “guest” is used here to indicate that the VM, although it acts as a “real” computer from the perspective of a user, is actually just computer code that is executed on the underlying “host” hardware and software platform 102, 150. Thus, for example, I/O to a virtual device 312 will actually be carried out by I/O to a corresponding hardware device 112, but in a manner transparent to the VM.
Some interface is usually required between the VM 300 and the underlying “host” hardware 102, which is responsible for actually executing VM-related instructions and transferring data to and from the actual physical memory 108, the processor(s) 104, the disk(s) 110 and the other device(s) 112. One advantageous interface between the VM and the underlying host system is often referred to as a virtual machine monitor (VMM), also known as a virtual machine “manager.” Virtual machine monitors have a long history, dating back to mainframe computer systems in the 1960s. See, for example, Robert P. Goldberg, “Survey of Virtual Machine Research,” IEEE Computer, June 1974, p. 34-45.
A VMM is usually a relatively thin layer of software that runs directly on top of host software, such as the system software 150, or directly on the hardware, and virtualizes the resources of the (or some) hardware platform. FIG. 1 shows virtualization software 200 running directly on the system hardware 102. The virtualization software 200 may be a VMM, for example. Thus, the virtualization software 200 is also referred to herein as a VMM 200. The VMM 200 will typically include at least one device emulator 202, which may also form the implementation of the virtual device 312. The VMM 200 may also include a memory manager 204 that maps memory addresses used within the VM 300 (for the virtual memory 308) to appropriate memory addresses that can be applied to the physical memory 108. The VMM also usually tracks and either forwards (to the host OS 152) or itself schedules and handles all requests by its VM for machine resources, as well as various faults and interrupts. FIG. 1 therefore illustrates an interrupt (including fault) handler 206 within the VMM. The general features of VMMs are well known and are therefore not discussed in further detail here.
FIG. 1 illustrates a single VM 300 merely for the sake of simplicity; in many installations, there will be more than one VM installed to run on the common hardware platform; all may have essentially the same general structure, although the individual components need not be identical. Also in FIG. 1, a single VMM 200 is shown acting as the interface for the single VM 300. It would also be possible to include the VMM as part of its respective VM, that is, in each virtual system. Although the VMM is usually completely transparent to the VM, the VM and VMM may be viewed as a single module that virtualizes a computer system. The VM and VMM are shown as separate software entities in the figures for the sake of clarity. Moreover, it would also be possible to use a single VMM to act as the interface for more than one VM, although it will in many cases be more difficult to switch between the different contexts of the various VMs (for example, if different VMs use different guest operating systems) than it is simply to include a separate VMM for each VM. This invention works with all such VM/VMM configurations.
In all of these configurations, there must be some way for the VM to access hardware devices, albeit in a manner transparent to the VM itself. One solution would of course be to include in the VMM all the required drivers and functionality normally found in the host OS 152 to accomplish I/O tasks. Two disadvantages of this solution are increased VMM complexity and duplicated effort—if a new device is added, then its driver would need to be loaded into both the host OS and the VMM. A third disadvantage is that the use of a hardware device by a VMM driver may confuse the host OS, which typically would expect that only the host's driver would access the hardware device. A different method for enabling the VM to access hardware devices has been implemented by VMware, Inc., in its ACE virtualization product. This method is also illustrated in FIG. 1.
In the system illustrated in FIG. 1, both the host OS 152 and the VMM 200 are installed at system level, meaning that they both run at the greatest privilege level and can therefore independently modify the state of the hardware processor(s). For I/O to at least some devices, however, the VMM may issue requests via the host OS. To make this possible, a special driver VMdrv 254 is installed as any other driver within the host OS 152 and exposes a standard API (Application Program Interface) to a user-level application VMapp 260. When the system is in the VMM context, meaning that the VMM is taking exceptions, handling interrupts, etc., but the VMM wishes to use the existing I/O facilities of the host OS, the VMM calls the driver VMdrv 254, which then issues calls to the application VMapp 260, which then carries out the I/O request by calling the appropriate routine in the host OS.
In FIG. 1, a vertical line 230 symbolizes the boundary between the virtualized (VM/VMM) and non-virtualized (host software) “worlds” or “contexts.” The driver VMdrv 254 and application VMapp 260 thus enable communication between the worlds even though the virtualized world is essentially transparent to the host system software 150.
FIG. 2 also illustrates the computer system 100 of FIG. 1, including some of the same components that are illustrated in FIG. 1, but FIG. 2 also illustrates some additional components of a particular implementation of the generalized hosted virtual computer system 100 of FIG. 1. Thus, FIG. 2 illustrates the following components that are also illustrated in FIG. 1, each of which may be the same as described above, except as described below: the system hardware 102, the CPU(s) 104, the MMU 106, the system memory 108, the disk 110, the device(s) 112, the host OS 152, the applications 160, the virtualization software 200 (which may be a VMM), the VM 300, the virtual system hardware 302, the virtual CPUs 304, the virtual system memory 308, the virtual disk 310, the virtual device(s) 312, the guest OS 352, the guest applications 360, and the virtualized/non-virtualized boundary 230.
FIG. 2 also illustrates a VM folder 120 that is stored on the disk 110. The VM folder 120 may be a conventional folder or directory, within a file system of the host OS 152. The VM folder 120 contains a number of conventional files, according to the file system of the host OS 152, including one or more VM configuration files 122 and one or more virtual disk files 124. The VM configuration files 122 may have any of a wide variety of formats, including possibly a standard text format, such as ASCII (American Standard Code for Information Interchange). The virtual disk files 124 typically have a format that is unique to the virtualization software 200 and that enables the virtualization software 200 to present data blocks within the virtual disk files as if they constitute a complete disk drive, namely the virtual disk 310. For example, the virtual disk 310 may comprise a certain number of data blocks, just like a physical disk, and each data block of the virtual disk 310 may be mapped to a specific data block within the virtual disk files 124. Information regarding the mapping from the data blocks of the virtual disk 310 to the data blocks in the virtual disk files 124 may also be contained within the virtual disk files 124, for example.
The files in the VM folder 120 define all aspects of the VM 300, at least when the VM 300 is not running. The VM configuration files 122 define all aspects of the virtual system hardware 302, except for the virtual disk 310. Thus, the VM configuration files 122 specify various items, such as how many virtual CPUs 304 there are, how much virtual system memory 308 there is and which virtual devices 312 there are. The virtualization software 200 reads the VM configuration files 122 to determine precisely what virtual system hardware 302 is to be emulated for the VM 300.
The virtual disk files 124 contain all of the data that appears, from the perspective of the VM 300, to be stored on the virtual disk 310. Thus, when the guest OS 352 is installed within the VM 300, the data blocks of the virtual disk files 124 that constitute the virtual disk 310 are effectively formatted in the same manner that the data blocks of a complete physical disk would be formatted, and the code and data of the guest OS 352 are written to data blocks of the virtual disk files 124 that correspond to the appropriate data blocks of the virtual disk 310. Similarly, when guest applications 360 are installed onto the virtual disk 310, the code and data for the applications are written to data blocks of the virtual disk files 124 that correspond with the locations on the virtual disk 310 to which the guest OS 352 intended that the applications be installed. All other code and data, such as user files created using the guest applications 360, are also stored in the virtual disk files 124 in a similar manner.
There are actually three different perspectives that may be considered here relative to the VM folder 120, the VM configuration files 122 and the virtual disk files 124. From the perspective of the host OS 152, the VM folder 120 is an ordinary folder in its file system containing ordinary files. The VM configuration files 122 may be ordinary text files, which the host OS 152 may read, display, print, search, etc., but the contents of these files are generally of no use to the host OS. The virtual disk files 124, however, typically have a format that is not understood by the host OS 152.
From the perspective of the virtualization software 200, the contents of the VM configuration files 122 can be read and used to determine precisely what virtual system hardware 302 should be emulated for use within the VM 300. Also, the format of the virtual disk files 124 is understood by the virtualization software 200, and the data blocks of the virtual disk files 124 are used by the virtual software 200 to emulate the virtual disk 310.
From within the VM 300, there is no direct access to the VM configuration files 122 or the virtual disk files 124. The guest software within the VM 300 and a user of the VM 300 only see the virtual system hardware 302 emulated by the virtualization software 200, based on the VM configuration files 122, and the virtual disk 310 emulated by the virtualization software 200, based on the virtual disk files 124.
FIG. 2 also shows a VM configuration/control interface application 262 running on the host OS 152, in the non-virtualized context. The configuration/control interface application 262 may be combined with the application VMapp 260 of FIG. 1 in some manner, such as by creating a single application that serves both purposes. This control interface application 262 provides a user interface to allow a user to create, configure and control the VM 300 (along with any other VMs that may exist in the computer system 100), while the host OS 152 is active. Thus, before the VM 300 exists, the control interface 262 enables a user to create the VM 300. The user can then use the control interface 262 to specify various characteristics of the virtual system hardware 302 that is to be included within the VM 300, such as how much virtual system memory 308 is to be provided, how large a virtual disk 310 is to be provided, and which virtual devices 312 are to be included. When the user creates the VM 300 and specifies the virtual system hardware 302, the control interface application 262 creates the VM folder 120, along with the VM configuration files 122 and the virtual disk files 124, including all the information needed by the virtualization software 200 to emulate the virtual system hardware 302, including the virtual disk 310, as specified by the user.
The user may then use the control interface 262 to cause the VM 300 to begin executing, and the user may cause the context of the computer system 100 to switch to the virtualized context of the virtualization software 200. The user may then operate within the VM 300 to install the guest OS 352 and the guest applications 360, just like on a physical computer system. The user can then run the guest applications 360 and use the guest OS 352, just like on a physical computer system. The user can also cause the computer system 100 to switch back to the non-virtualized context of the host OS 152, such as by a particular set of key strokes on the keyboard of the computer system 100. Once the system switches back to the non-virtualized context, the user can use the applications 160 and the host OS 152, just as if the computer system 100 had no virtualized context. The user can also use the control interface application 262 to take a variety of actions relative to the VM 300 or other VMs in the computer system 100. For example, the user can use the control interface 262 to modify the virtual system hardware 302 that is provided within the VM 300, such as by adding an additional virtual device 312. The user can also use the control interface 262 to take various other actions relative to the VM 300, such as pausing the VM, suspending the VM, resuming the VM, and creating a redo log for the virtual disk 310. When the user takes such actions through the control interface 262, the control interface interacts with the virtualization software 200 to effect the actions; and/or the control interface 262 and/or the virtualization software 200 modify the VM configuration files 122 and/or the virtual disk files 124, as needed. Thus, for example, if the user adds another virtual device 312 to the VM 300, the control interface application 262 may modify the VM configuration files 122 to specify the added virtual device.
The user may also use other applications 160 and/or the host OS 152 to access the VM folder 120, the VM configuration files 122 and the virtual disk files 124 directly. For example, the user may copy the entire VM folder 120 to another physical computer, such as through a network connection, although the virtual disk files 124 may be very large, as they contain the entire contents of the virtual disk 310, including the guest OS 352 and the guest applications 360. Also, the user may use an application 160, for example, to display the contents of the VM configuration files 122, especially if the VM configuration files are simple text files. The user may be able to figure out the structure of the contents of the VM configuration files 122 and may be able to change the virtual system hardware 302, for example, by directly editing the VM configuration files 122. The vendor of the virtualization product may also provide information and/or tools that facilitate the direct manipulation of the VM configuration files 122. The user may also directly access the virtual disk files 124 for a variety of purposes, although the format of the virtual disk files 124 typically makes such access a little more challenging.
A user of the virtual computer system 100 of FIGS. 1 and 2 has great freedom to perform a wide variety of actions with and to the VM 300. The user can create the VM 300; configure the VM; modify the configuration of the VM; display, modify or copy the VM configuration files 122 and/or the virtual disk files 124; and control the operation of the VM, such as starting and stopping the VM. Depending on the capabilities provided by the virtual system hardware 302, the user may also use the VM 300 to take a variety of other actions. For example, if the virtual system hardware 302 includes a device 312 that is a floppy disk drive, which is implemented through a floppy disk drive of the physical computer, then the user may copy data between the virtual disk 310 (actually the virtual disk files 124 on the physical disk 110) and a floppy disk in the floppy disk drive. Also, if the virtual system hardware 302 includes a device 312 that is a NIC (Network Interface Card), which is implemented through a NIC of the physical computer, then the user may be able to access a LAN and/or the Internet, and download programs, copy data, send and receive emails, etc.